Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-087

Text File | 1995-12-31 | 86.4 KB | 2,141 lines | [TEXT/R*ch]

C.S.M.P. Digest             Tue, 07 Mar 95       Volume 3 : Issue 87

Today's Topics:

        Aliases
        How to write to same directory as App??
        INITGestalt Proposal
        Information on installer maker companies
        Sound Manager clicking with sampled sounds
        VBL, time manager interrupts on PPC
        anything *bad* about mixing alignment types in CW?
        custom ClikLoop problem



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                                Sends you a summary of commands
    subscribe csmp-digest Your Name     Adds you to the mailing list
    signoff csmp-digest                 Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail].

-------------------------------------------------------

>From [e-mail] (Steve Patt)
Subject: Aliases
Date: 17 Feb 1995 18:17:59 GMT
Organization: California Institute of Technology, Pasadena

Situation: If a file is modified, my program renames the original as
  "XXX Backup", then saves the new file as "XXX".

Problem: This seems to run into a problem with aliases. For example,
  Launcher in Sys 7.5, or the "Recent Documents" Apple menu item (again in 7.5),
  both use aliases to point to a file. After I do the rename and save a new
  file as described, it seems that the alias still points to the original
  file. So someone uses "Recent Documents" to open the document, but actually
  what opens is the _backup_, not the new file. THIS IS BAD.

Workaround: Clearly I could work around this by _copying_ the original file to
  "XXX Backup", and then just overwriting the file with the new file. But this
  will take twice as long to write to disk (since I'll basically be writing the
  file twice).

Question: Is there a way to deal with this?

Steve Patt
Stevens Creek Software
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (David Shaw)
Date: 18 Feb 1995 15:28:46 GMT
Organization: INTAC Access Corp

In comp.sys.mac.programmer.help, [e-mail] (Steve Patt) writes:
>Situation: If a file is modified, my program renames the original as
>  "XXX Backup", then saves the new file as "XXX".
>
>Problem: This seems to run into a problem with aliases. For example,
>  Launcher in Sys 7.5, or the "Recent Documents" Apple menu item (again in 7.5)
>,
>  both use aliases to point to a file. After I do the rename and save a new
>  file as described, it seems that the alias still points to the original
>  file. So someone uses "Recent Documents" to open the document, but actually
>  what opens is the _backup_, not the new file. THIS IS BAD.

You might try looking into the FSpExchangeFiles call.  Save your
"changed" file as "XXX Backup" and then swap it with "XXX".  I believe
(but I am not 100% sure) that FSpExchangeFiles correctly handles aliases.

David

+++++++++++++++++++++++++++

>From [e-mail] (Reinder Verlinde)
Date: Mon, 20 Feb 1995 12:24:32 GMT
Organization: Rijksuniversiteit Utrecht

In article <[e-mail]>,
[e-mail] (Steve Patt) wrote:

> Situation: If a file is modified, my program renames the original as
>   "XXX Backup", then saves the new file as "XXX".
>
> Problem: This seems to run into a problem with aliases. For example,
>   Launcher in Sys 7.5, or the "Recent Documents" Apple menu item (again
in 7.5),
>   both use aliases to point to a file. After I do the rename and save a new
>   file as described, it seems that the alias still points to the original
>   file. So someone uses "Recent Documents" to open the document, but actually
>   what opens is the _backup_, not the new file. THIS IS BAD.
>
> Workaround: Clearly I could work around this by _copying_ the original file to
>   "XXX Backup", and then just overwriting the file with the new file. But this
>   will take twice as long to write to disk (since I'll basically be
writing the
>   file twice).
>
> Question: Is there a way to deal with this?
>
> Steve Patt
> Stevens Creek Software
> [e-mail]

Yes, just write the new file to the ' backup' file and then use FSpExchangeFiles
(not sure about the exact name). It is made for it. See IM VI for details.

Reinder Verlinde

+++++++++++++++++++++++++++

>From [e-mail] (Chris Tate)
Date: Tue, 21 Feb 1995 15:15:08 GMT
Organization: DCRT, NIH, Bethesda, MD

In article <[e-mail]>, [e-mail] (Steve Patt) writes:
>
>Workaround: Clearly I could work around this by _copying_ the original file to
>  "XXX Backup", and then just overwriting the file with the new file. But this
>  will take twice as long to write to disk (since I'll basically be writing the
>  file twice).

Just an idea (since I don't have my Inside Macs available at the moment),
but isn't this exactly the sort of thing that FSpExchangeFiles() was
designed to address?

Write the *new* file as "XXX Backup," then call FSpExchangeFiles() to
swap its directory entries with the outdated file.  I *think* this will
accomplish the necessary alias-rerouting. At least, it's worth a little
test....  :-)

(I can't do the test, unfortunately.  I'm chained to a Windows machine for
a few months, and don't get to work on the Mac for a while.  Fooey. :-(

- ----------------------------------------------------------
Christopher Tate           | "I love it when you use me as
[e-mail]  |  a split-screen montage!"
eWorld:  cTate             |   -- "Whose Line Is It Anyway?"

---------------------------

>From [e-mail] (Carl B. Constantine)
Subject: How to write to same directory as App??
Date: Tue, 14 Feb 1995 11:19:34 -0700
Organization: Ministry of Environment, Lands & Parks

I'm looking at a program I'm writting and one thing I would like to do is
read and write specific files for my program in the SAME FOLDER as my
program.

FSpCreate takes an FSSpec record and stuff.  How do I know what directory
and volume my program is in/on?  I want to read and write a specific
filename to this directory.  Do I find out where my program is and then
read/write the file? if how do I do that?

Some programs (Mosaic for example) have a dialog that shows the full path
to a particular folder.  How do I create something similar and maybe use
the full pathname to read/write the file(s) I need?

Thanks for any help you can give!

Any code is usefull.  Post also to alt.sources.mac as others would be
interested in this.

--
========================================================================
Carl B. Constantine                  B.C. Environment, Lands & Parks
Systems Officer                      [e-mail]
"Remember, no matter where you go - there you are" - Buckaroo Bonzai

+++++++++++++++++++++++++++

>From [e-mail] (Sardaukar)
Date: 14 Feb 1995 21:28:03 -0500
Organization: America Online, Inc. (1-800-827-6364)

Here's how Apple answered the same question when I asked it years ago:

>Is there a cool, modern way to get the FSSpec record of the running
application?  I was going to use GetApParms to find the name, and GetVol
to get the vRef, and i'd somehow figure out the dirID (btw, how *do* you
figure out the dirID??), and do a MakeFSSpec, but I imagine that there
must be a better way that doesn't rely on old functions and system
globals.

For the first question, here are three methods that you could use.  The
first
uses the Process Manager to get the application's location.  If you have
the
Process Manager available, you should use it:

   FUNCTION GetAppLocFromPM (VAR spec: FSSpec): OSErr;
      VAR
         PSN: ProcessSerialNumber;
         info: ProcessInfoRec;
   BEGIN
      info.processInfoLength := sizeof(ProcessInfoRec);
      info.processName := NIL;
      info.processAppSpec := @spec;
      PSN.highLongOfPSN := 0;
      PSN.lowLongOfPSN := kCurrentProcess;
      GetAppLocFromPM := GetProcessInformation(PSN, info);
   END;

The second gets the application's location by getting the information from
the
application's resource fork refNum (returned by CurResFile).  Just make
sure
you don't change the current resource file before using this function:

   FUNCTION GetAppLocFromCurResFile (VAR spec: FSSpec): OSErr;
      VAR
         err: OSErr;
         fcbPB: FCBPBRec;
         fileName: Str255;
   BEGIN
      WITH fcbPB DO
         BEGIN
            ioNamePtr := @fileName;
            ioVRefNum := 0;
            ioRefNum := CurResFile;
            ioFCBIndx := 0;
         END;
      err := PBGetFCBInfoSync(@fcbPB);
      IF err = noErr THEN
         err := FSMakeFSSpec(fcbPB.ioFCBVRefNum, fcbPB.ioFCBParID,
fileName,
spec);
      GetAppLocFromCurResFile := err; { return any errors }
   END;

The third method gets the application's location by getting the
information
from the application's resource fork refNum (returned by GetAppParms):

   FUNCTION GetAppLocFromGetAppParms (VAR spec: FSSpec): OSErr;
      VAR
         err: OSErr;
         fcbPB: FCBPBRec;
         fileName: Str255;
         apParam: Handle;
   BEGIN
      GetAppParms(fileName, fcbPB.ioRefNum, apParam);
      WITH fcbPB DO
         BEGIN
            ioNamePtr := @fileName;
            ioVRefNum := 0;
            ioFCBIndx := 0;
         END;
      err := PBGetFCBInfoSync(@fcbPB);
      IF err = noErr THEN
         err := FSMakeFSSpec(fcbPB.ioFCBVRefNum, fcbPB.ioFCBParID,
fileName,
spec);
      GetAppLocFromGetAppParms := err; { return any errors }
   END;

Note that the second and third methods given don't return the same
location as
the Process Manager if you're running you code under the THINK development
environment, but they all work the same in stand-alone applications. Under
THINK Pascal or C, the location returned by GetAppParms and CurResFile are
the
location of the project file - the Process Manager returns the location of
THINK Pascal or C.


+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: 15 Feb 1995 04:14:52 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <[e-mail]>,
[e-mail] (Carl B. Constantine) wrote:

< FSpCreate takes an FSSpec record and stuff.  How do I know what directory
< and volume my program is in/on?  I want to read and write a specific

< ========================================================================
< Carl B. Constantine                  B.C. Environment, Lands & Parks
< Systems Officer                      [e-mail]
< "Remember, no matter where you go - there you are" - Buckaroo Bonzai

Use the process manager calls GetCurrentProcess() and GetProcessInfo().
The process info rec has the fsspec of the app in it, along with other fun
info.

Good luck,

--
Brian  Stern  :-{)}
Toolbox commando and Menu bard
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Steve Lay)
Date: Wed, 15 Feb 1995 09:27:08 +0000
Organization: DAMTP, Cambridge University

This came up a few days ago too in another guise.  Here's how to get an
FSSpec for your application using the Process Mgr (where available):

    {
    ProcessSerialNumber psn;
    ProcessInfoRec pInfo;
    FSSpec file;
    OSErr err;

    psn.highLongOfPSN=0;
    psn.lowLongOfPSN=kCurrentProcess;
    pInfo.processInfoLength=sizeof(ProcessInfoRec);
    pInfo.processName=nil;
    pInfo.processAppSpec=&file;
    err=GetProcessInformation(&psn,&pInfo);
    }

Steve

--
Steve Lay
Interactive Courseware Research & Development

[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Wed, 15 Feb 1995 07:56:34 -0800
Organization: Internet for the Olympic Peninsula

In article <[e-mail]>,
[e-mail] (Carl B. Constantine) wrote:

> I'm looking at a program I'm writting and one thing I would like to do is
> read and write specific files for my program in the SAME FOLDER as my
> program.

Others have given answers.  [Also look around in the routines in the
MoreFiles collection.]

But...no problem if you are writing for yourself.  If writing for
distribution, you need to do something about the case where the user
doesn't have write access to the folder containing your application (it's
on a server from a folder without write permission for some user; it's
running from CD...[easier to forbid the latter than the former]).

So you need some sort of fallback.  That's where the Preferences folder
came from:  the user by definition does have write access to the System
folder (or some other location of the Preferences, now that booting from
CD is possible).

   --John

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
       Isn't C fun?
   [e-mail]

---------------------------

>From [e-mail] (Rene G.A. Ros)
Subject: INITGestalt Proposal
Date: Wed, 1 Feb 1995 10:55:36 GMT
Organization: VU Biology, Amsterdam, The Netherlands



                                     Pembury UK/Amsterdam NL, 31 Januari 1995

Dear Fellow programmers,

Some time ago we found a need for a way to obtain information about
installed software in a standardized way. The Gestalt Manager provides an
excellent mechanism for this and we decided the best thing to do was to
design a record structure to which a pointer was obtained by using a normal
Gestalt call. This record structure was designed to provide the basic
features needed but allows for addition of future attribute bits and
fields.
Indeed, during the design of this structure it was found useful to include
a pointer to a control function as well. Using this control function
software can receive messages to change settings or to obtain more
information.
We have called this mechanism 'INITGestalt' but it is also usable by
software other than extensions.
Included below is the latest version of our proposal (1.0b1) which we like
to discuss with you. Also available are a C and Pascal header file. The
full package (proposal and header files) can be obtained by sending an
email to
    [e-mail]
with as subject
    archive get INITGestalt*


Please post replies instead of using email.


Best Regards,

Jeremy Roussak ([e-mail])

Rene G.A. Ros ([e-mail])


     with contributions from:
          Dave Ely ([e-mail])
          Bill Hofmann ([e-mail])
          John Mancino ([e-mail])
          Jens Miltner ([e-mail])
          Alessandro Levi Montalcini ([e-mail])
          Fabrizio Oddone ([e-mail])
          Quinn "The Eskimo" ([e-mail])
          Hans Verbrugge ([e-mail])



INITGestalt: a proposal
=======================

Version 1.0b1
Last modified: 31 January 1995

It is often useful for an extension, or indeed an application, to know
whether certain other extensions are running (the term "extensions"
primarily includes system extensions, control panels and background-only
applications, although there is no reason why it should not include
ordinary applications). The reasons could be to take evasive action to
avoid conflicts with other extensions, to co-operate with another
extension, perhaps by using that extension's features, or possibly to
disable similar features. Equally, it could be useful for one extension
temporarily to turn off another: witness the "toggle Super Boomerang" FKEY
and the QuicKeys extension for Scroll2.

Fortunately, since system 6.0.4 a system-supported mechanism has existed
whereby this could be achieved: Gestalt.

We would therefore like to propose a standard to which writers of software
could adhere. The success of ShowINIT indicates that such a de facto
standard can emerge.

1. Every extension should register a Gestalt selector equal to its
signature. If Gestalt subsequently returns gestaltUndefSelectorErr, the
extension is not loaded.

2. The value returned by Gestalt is of suffix type Table: that is, a
pointer to more data. The block to which the pointer points is already
allocated and should not be disposed, since it might be part of a larger
memory block. The returned value may be nil if the installed software is
disabled and removed from memory, or when the application has quit. The
Gestalt definition function which returns the value should not move memory
and should be safe to be called at interrupt time.

3. The minimum table returned should contain the record described below.
The table returned is read-only.

C:
typedef struct
{
        OSType          recType;                        // must always be kGestaltRecordType
        NumVersion      recVersion;                     // the version of the record format
        NumVersion      version;                        // version of installed software
        ulong           stdAttr;                        // attribute bits defined by standard
        ulong           reserved1;                      // reserved, for more attribute bits
        ulong           custAttr;                       // attribute bits defined by software
        ProcessSerialNumber     process;        // PSN of installer
        ulong           reserved2;                      // reserved
        UniversalProcPtr        Control;        // pointer to a control function
        ulong           refCon                          // pointer or handle for private use
// optionally, more software-specific data may
// follow directly as part of the same structure
} INITGestaltRec, *INITGestaltRecPtr, **INITGestaltRecHandle;

enum
{
        kIGRecType                              = 'JRRR',
        kIGRecCurrentVersion    = $01006001,

        //      bit constants for the stdAttr field
        kIGEnabled = 0,
        kIGDebugVersion,
        kIGDebugEnabled,
        kIGPPCNative,
        kIGAcceptsAEvents,

        // basic selectors for the Control function
        kIGCtrlEnableGet                = 0,
        kIGCtrlEnableSet,
        kIGCtrlDebugGet,
        kIGCtrlDebugSet,
        kIGCtrlGetFSSpec,
        kIGCtrlGetMemSize,

        // user selector area
        kIGFirstUserSelector    = 1000

        // result codes for the Control function
        kIGNoErr                                = noErr,        // No Error
        kIGUnimplErr                    = 5554,         // Control function selector not
                                                                                //      implemented
        kIGAnswerUnknown                = 5555,         // Requested information not
                                                                                //      available
        kIGMsgInvalidErr                = 5556,         // Message parameter invalid
}


PASCAL:
type
INITGestaltRec =        record
        recType:        OSType;                         {must always be kGestaltRecordType}
        recVersion:     NumVersion;                     {the version of the record format}
        version:        NumVersion;                     {version of installed software}
        stdAttr:        LongInt;                        {attribute bits defined by standard}
        reserved1:      LongInt;                        {reserved, for more attribute bits}
        custAttr:       LongInt;                        {attribute bits defined by software}
        process:        ProcessSerialNumber     {PSN of installer}
        reserved2:      LongInt;                        {reserved}
        Control:        UniversalProcPtr;       {pointer to a control function}
        refCon:         LongInt;                        {pointer or handle for private use}
        { optionally, more software-specific data may }
        { follow directly as part of the same structure }
        end;

INITGestaltRecPtr = ^INITGestaltRec;
INITGestaltRecHandle = ^INITGestaltRecPtr;

const
        kIGRecType                              = 'JRRR';
        kIGRecCurrentVersion    = $01006001;

        {bit constants for the stdAttr field}
        kIGEnabled                              = 0;
        kIGDebugVersion                 = 1;
        kIGDebugEnabled                 = 2;
        kIGPPCNative                    = 3;
        kIGAcceptsAEvents               = 4;

        {basic messages for the Control function}
        kIGCtrlEnableGet                = 0;
        kIGCtrlEnableSet                = 1;
        kIGCtrlDebugGet                 = 2;
        kIGCtrlDebugSet                 = 3;
        kIGCtrlGetFSSpec                = 4;
        kIGCtrlGetMemSize               = 5;
        {user selector area}
        kIGFirstUserSelector    = 1000;

        {result codes for the Control function}
        kIGNoErr                                = noErr;        {No Error}
        kIGUnimplErr                    = 5554;         {Control function selector not}
                                                                                {       implemented}
        kIGAnswerUnknown                = 5555;         {Requested information not}
                                                                                {       available}
        kIGMsgInvalidErr                = 5556;         {Message parameter invalid}


recType
        This field must always contain 'JRRR' (kIGRecType) to indicate it
        supports the INITGestaltRec as defined by this standard.

recVersion
        Contains a version number indicating the version of the INITGestalt
        standard to which the INITGestaltRec complies. This field should be
        filled using the kIGRecCurrentVersion constant. The version number is
        in the same format as the first four bytes of a 'vers' resource.
        This version number changes when fields are added or changed and also
        when more attribute bits are defined.

version
        Holds the version of installed software in the same format as the first
        four bytes of a 'vers' resource.

stdAttr
        Holds attribute bits defined by this standard to indicate certain
        capabilities. The following bits are currently defined, the others must
        always be set to zero.

        kIGEnabled
                If set, the installed software is currently enabled.

        kIGDebugVersion
                If set, the installed software is a debugging version.

        kIGDebugEnabled
                If set, the installed software is a debugging version and supports
                a debug mode which can be turned on and off (this bit can never be
                set if kIGDebugVersion is unset).

        kIGPPCNative
                If set the installed software is fully PowerPC native code or
                contains "fat" trap patches

        kIGAcceptsAEvents
                If set, the installed software can accept AppleEvents

reserved1
        Reserved, possibly for more attribute bits defined by this standard.
        Should be set to zero.

custAttr
        Holds attribute bits defined by the software which installed this
        selector pointing to the INITGestaltRec record. The developer can use
        this field for attribute bits only and should define them with the
        documentation as much as possible. Undefined bits must always be set to
        zero.

process
        Holds the Process Serial Number of the process which installed this
        selector. If no process is associated this field must be zero
        (kNoProcess). The other Process Manager constants kSystemProcess and
        kCurrentProcess should not be used.

reserved2
        Reserved for future use. Should be set to zero.

Control
        Address to a function which can control the software. In addition, it
        can be used to return more info from the installed software to other
        applications than possible with the other mechnisms of this standard
        If the control function can't be used set this field to nil.

        The control function must look like this:

                C:              pascal OSErr IGControl (long selector, void *message);
                PASCAL: Function IGControl (selector: LongInt;
                                                                        var message: LongInt): OSErr;

        The IGControl function allows the extension to be controlled by other
        applications or to return information requested by other applications.
        The selector variable indicates what type of control is applied or what
        type of information is requested. All values between 0 and
        kIGFirstUserSelector (which translates to 1000) are reserved for use by
        this standard. All positive values starting at kIGFirstUserSelector are
        free to be used by your software. Negative values should not be used.
        Calling this function should be safe at interrupt time.
        If the software allows control by Apple events it should implement this
        Control function, even if it duplicates the task of Apple events. This
        function is more generic and doesn't require knowledge about a private
        event class.

        Below is a list of selector values defined with this standard. None of
        these selectors are required to be implemented, but we ask you to
        implement them when possible.

        (Note to Pascal users: 'a pointer to a Boolean value' simply means that
         you have to cast the message parameter to a Boolean. This description
         is useful for C programmers, since Pascal knows the var mechanism).

        kIGCtrlEnableGet
                Retrieves the current state of the installed software. The message
                parameter is a pointer to a Boolean value, which is ignored on input
                but is set to 0 (inactive) or 1 (active) on return.
                If the software does not support disabling it should put 1 in
                the message parameter and return kIGNoErr.
                This selector can be used together with the kIGCtrlEnableSet
                selector which is described below.

        kIGCtrlEnableSet
                Enables or disables the installed software temporary depending on
                the input value of the message parameter (pointer to a Boolean
                value). Changing the state should not survive stopping and starting
                the software (by quitting or restart)
                Passing 0 (zero) in the message parameter disables the software,
                while 1 (one) enables it. The message should contain the previous
                state after completion. The Control function code should change the
                kIGEnabled bit accordingly.
                If the software does not support disabling it should return a
                kIGUnimplErr error message.
                This selector can be used to temporary disable software, i.e.
                to prevent conflicts.

        kIGCtrlDebugGet
                Retrieves the current state of the debug mode of the installed
                software. The message parameter is a pointer to a Boolean value,
                which is ignored on input but is set to 0 (inactive) or 1 (active)
                on return.
                If the software does not support a debug mode it should put 0 in
                the message parameter and return kIGNoErr.
                This selector can be used together with the kIGCtrlDebugSet
                selector which is described below.

        kIGCtrlDebugSet
                Enables or disables the debug mode of the installed software
                depending on the input value of the message parameter (pointer to a
                Boolean value).
                Passing 0 (zero) in the message parameter turns the debug mode off,
                while 1 (one) turns it on. The message should contain the previous
                state after completion. The Control function code should change the
                kIGDebugEnabled bit accordingly.
                If the software does not support a debug mode it should return a
                kIGUnimplErr error message.
                This selector allows other software to turn the debug mode of the
                software on or off on the fly. This can be useful for certain
                utilities which are part of your software suite.

        kIGCtrlGetFSSpec
                Returns the location of the installed software as an FSSpec. The
                message parameter should contain a pointer to a FSSpec record which
                will be filled by the Control function.
                The function result should be kIGAnswerUnknown when the location is
                unknown or the user moved the software and it cannot be found.
                This selector can be used to determine the location of the active
                part of the software and allow management software to move it outside
                the system folder.

        kIGCtrlGetMemSize
                Returns the total memory usage of the installed software. The
                message parameter is of type Size and holds on return the total
                memory usage in bytes.
                If the memory size is unknown the function result must be
                kIGAnswerUnknown.
                This selector can be used to determine the memory usage by your
                software for display purposes and statistics.

        If you define your own selector and you think it may be usefull to have
        it defined with this standard, please let the undersigned know about
        it.
        Please publish the selectors, you defined for your own use, in the
        documentation of your software. Ofcourse you're free to keep them
        private if you really want.
        The function returns kIGNoErr if it succeeds, otherwise an OSErr
        explaining why it failed. The following error messages can be used:

        kIGNoErr
                No error occured, the Control function executed properly.

        kIGUnimplErr
                The selector code is not implemented by the called Control
                function.

        kIGAnswerUnknown
                The selector code is implemented but the requested information
                could not be returned.

        kIGMsgInvalidErr
                The message code was found to be invalid by the Control function
                for use with the specified selector.

refCon
        Pointer or Handle to another block with custom and/or private data.
        Should be nil if not used. In any event, the caller should not attempt
        to dispose of the data block to which refCon points. One obvious use
        of refCon would be to allow communication between a control panel and
        its INIT component.

4. Further extension-specific data could follow. This could include further
communication functions to allow more detailed control or use of the
extension, if this were deemed desirable.

5. If your software installs a selector which adopts this standard, you
should email your documentation, which includes a description of the custom
fields, to Rene G.A. Ros for inclusion with the Gestalt Selectors List
(GSL). An entry in the GSL would look like this:

        ======================================================================
        SWVE (SimpleWave ext [1.0b1] by Rene G.A. Ros)
             gestaltSimpleWaveTable
             Returns a pointer to an INITGestalt structure.

             const
             gestaltSimpleWaveTable = 'SWVE';
        ======================================================================


The code required to implement the basic functionality would be very small
and very easy to write.

Comments on this proposal please: post rather than email.

Jeremy Roussak ([e-mail])

Rene G.A. Ros ([e-mail])


The following persons contributed ideas and corrections for which we want
to thank them:
        Dave Ely ([e-mail])
        Bill Hofmann ([e-mail])
        John Mancino ([e-mail])
        Jens Miltner ([e-mail])
        Alessandro Levi Montalcini ([e-mail])
        Fabrizio Oddone ([e-mail])
        Quinn "The Eskimo" ([e-mail])
        Hans Verbrugge ([e-mail])

- -------------------------------------------------------------------------
Changes
        1.0b1 (31 January 1995)
        -       changed recVersion to NumVersion type.

- -------------------------------------------------------------------------
History
This proposal was initially written in 1992 for use by extensions by
Jeremy Roussak based on an idea by Rene Ros. It never saw daylight because
of other projects. After almost two year we saw some need for changes and
to make it generally usuable for applications as well.

+++++++++++++++++++++++++++

>From [e-mail] (David Phillip Oster)
Date: Thu, 2 Feb 1995 09:20:40 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)

In article <3gpd2i$[e-mail]> [e-mail] ([e-mail]) writes:

_>First, I will point out the two weaknesses of a pure gestalt approach,

_>1) Gestalt is quite well suited to the task, but there is an
_>ever-so-slight performance penalty as more selectors are added to the
_>Gestalt table.
_>2) The current mechanism offers no enumeration capabilities.
_>there is no simple way to ask the question "what extensions are
_>installed?"
_>So, what I propose is that there be _one_ selector which serves as a
_>jumping off point for registration of all extensions.  This selector
_>points to a simple OS QHdr.  Enqueue'd on this header are records of
_>type INITGestaltRec (as per the previous spec) with two slight
_>modifications: ...

Congratulations, you've just re-invented the wheel. I agree with the
problems,., but solution is Component Manager, which already exists,
not another piece of code that does the same thing.
--
- ------- [e-mail] ----------
There is no sight finer than that of the planet Earth in your rearview mirror.



+++++++++++++++++++++++++++

>From [e-mail] ([e-mail])
Date: 2 Feb 1995 15:51:13 GMT
Organization: Dartmouth College, Hanover, NH

In article <[e-mail]>
[e-mail] (David Phillip Oster) writes:
> Congratulations, you've just re-invented the wheel. I agree with the
> problems,., but solution is Component Manager, which already exists,
> not another piece of code that does the same thing.

Well, gee...  Maybe you can point out how the Component Manager can be
used to do this and thus join in the discussion with some real
information.

For instance, I'm not convinced that the Component Manager is the right
solution (I don't know that much about it, though).  What I do know is
that the Component Manager was originally part of QuickTime.  Is it
built into all versions of System 7?  When does it load?  Can it be
loaded by an INIT if it is not there?  Will we have to license it from
Apple in order to get it on System 7.0?  Can it run under System 6
(this would be good, because Gestalt is not implemented on all
systems)?  What are the real drawbacks, if there are any?

I agree that the design of this INIT Gestalt gizmo has much in common
with the Component Manager, but the code is so ultra-trivial that it
would not really be "re-inventing the wheel" to write a few queue
access routines.

So, convince everyone (who's listening) that the Component Manager is
the way to go, and you may just save us from ourselves ;-)

Mark.

+++++++++++++++++++++++++++

>From [e-mail] (Grobbins)
Date: 6 Feb 1995 11:17:04 -0800
Organization: Skunkworks

Publicizing pointers and handles with the Gestalt Manager is convenient,
but it's also an abuse of the Gestalt facility.  The notion of getting
a pointer to a completely independent piece of code is very non-savvy
with respect to any future architectures that provide for multiple
address spaces.

There are supported interfaces usable by non-application code, such as
the interfaces provided for drivers and components, and the PPC Toolbox
is a supported communications mechanism for all types of code.  Passing
around handles and procptrs may be simple, but it's poor practice and
will tend to bite you later.

Grobbins                      [e-mail]

Usual disclaimers apply.


+++++++++++++++++++++++++++

>From [e-mail] (Grobbins)
Date: 6 Feb 1995 11:17:04 -0800
Organization: Skunkworks

Publicizing pointers and handles with the Gestalt Manager is convenient,
but it's also an abuse of the Gestalt facility.  The notion of getting
a pointer to a completely independent piece of code is very non-savvy
with respect to any future architectures that provide for multiple
address spaces.

There are supported interfaces usable by non-application code, such as
the interfaces provided for drivers and components, and the PPC Toolbox
is a supported communications mechanism for all types of code.  Passing
around handles and procptrs may be simple, but it's poor practice and
will tend to bite you later.

Grobbins                      [e-mail]

Usual disclaimers apply.


+++++++++++++++++++++++++++

>From [e-mail] (Caleb Strockbine)
Date: 10 Feb 1995 16:07:45 GMT
Organization: SUNY Stony Brook

In article <3herhv$[e-mail]> [e-mail] ([e-mail]) writes:
>In article <3h5sjg$[e-mail]>, [e-mail] (Grobbins) wrote:
>> There are supported interfaces usable by non-application code, such as
>> the interfaces provided for drivers and components, and the PPC Toolbox
>> is a supported communications mechanism for all types of code.  Passing
>> around handles and procptrs may be simple, but it's poor practice and
>> will tend to bite you later.

I'd have to agree with Grobbins. Seems like there are plenty of supported
mechanisms for providing services for all processes. Why abuse the Gestalt
manager when you can use another manager properly?

>Now, what is the chance of old-style INITs being around in a system
>with seperate memory spaces?  Oh, so you'll put all extensions in one
>common memory space (or a shared system area in each app's space)?
>Well, uh, doesn't that mean we can pass pointers without fear of memory
>faults?

I'd say the probability of someone using old extensions in a new system
must be 1. Sure, passing pointers around inside a common memory space would
be okay, but that means that nobody else could use your INITGestalt package.
Why shouldn't processes in other memory spaces be able to use it as well?

>So far, suggestions for using the Component Manager and PPC Toolbox
>have been made, but with not a hint about how they might be used.
>Perhaps when a suggestion is made, the author could include at least
>one argument why their method is worth considering, possibly with an
>outline of how the method might be implemented.  Hmmm?

You could use the Component Manager in a couple of ways. One would be to
write a standard component which maintains a database of services which
register themselves. Another would be to have each extension register itself
as a component of type 'INIT' or something like that. The Component
Manager provides nice tools for finding particular components or all
the components of a particular type, which seems to be the functionality
you're looking for. Extensions registering as components could support
any number of useful functions, including calls to turn them on/off,
provide information about themselves, report how much memory they're
currently using, report whether they're currently working or not and
why ("This extension was turned off by the user"/"This extension doesn't
work with virtual memory"), etc. Individual extensions could also provide
extended interfaces for easy integration with other kinds of code.
Hmmm... this is sounding good... maybe I'll go write some of this up
tonight.

I don't remember all that much about the PPC toolbox, but one would
imagine that it supports a similar registration system that extensions
could use to register themselves and which other processes could use to
find such registered extensions.

Both of these systems are better than using Gestalt to pass function
pointers around simply because they make use of the OS as it was
intended to be used. They don't make assumptions that might limit
Apple's ability to extend the OS or which might break in future
revisions of the OS. Using Gestalt for interprocess communication
is pretty skanky.

Caleb Strockbine





--

.........................................................................
"It isn't always just how you look. Look at me. I'm handsome like anything
 and I haven't got anybody to marry me yet." -- Brian, age 7

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: 11 Feb 1995 16:31:41 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <3h5sjg$[e-mail]>, [e-mail] (Grobbins) wrote:

< Publicizing pointers and handles with the Gestalt Manager is convenient,
< but it's also an abuse of the Gestalt facility.  The notion of getting
< a pointer to a completely independent piece of code is very non-savvy
< with respect to any future architectures that provide for multiple
< address spaces.
<
< There are supported interfaces usable by non-application code, such as
< the interfaces provided for drivers and components, and the PPC Toolbox
< is a supported communications mechanism for all types of code.  Passing
< around handles and procptrs may be simple, but it's poor practice and
< will tend to bite you later.
<
< Grobbins                      [e-mail]
<
< Usual disclaimers apply.

Admonishing developers to do things the right way is all well and good but
what we really need is working example code.  People use Gestalt for this
because it is much simpler to implement than PPC-toolbox.  Most people are
familiar with the Gestalt Manager; few are familiar with PPC-toolbox.

I remember looking at the INIT-CDEV example when I first needed this
functionality and thinking that it was too complicated.  I just looked at
it again and I understand it better now.  Of course this example goes to
all this trouble to make a PPC-Toolbox connection between the INIT and the
CDEV and what information does it pass?  A pointer to the INIT's globals.
Oh well.

--
Brian  Stern  :-{)}
Toolbox commando and Menu bard
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] ([e-mail])
Date: 11 Feb 1995 18:09:17 GMT
Organization: Dartmouth College, Hanover, NH

In article <3hg30h$[e-mail]>
[e-mail] (Caleb Strockbine) writes:
> In article <3herhv$[e-mail]> [e-mail] ([e-mail]) writes:
> >In article <3h5sjg$[e-mail]>, [e-mail] (Grobbins) wrote:
> >> There are supported interfaces usable by non-application code, such as
> >> the interfaces provided for drivers and components, and the PPC Toolbox
> >> is a supported communications mechanism for all types of code.  Passing
> >> around handles and procptrs may be simple, but it's poor practice and
> >> will tend to bite you later.
>
> I'd have to agree with Grobbins. Seems like there are plenty of supported
> mechanisms for providing services for all processes. Why abuse the Gestalt
> manager when you can use another manager properly?

I think most of us (well, I can only speak for myself) agree with that
on the most general level, as well as in this specific case.

> >Now, what is the chance of old-style INITs being around in a system
> >with seperate memory spaces?  Oh, so you'll put all extensions in one
> >common memory space (or a shared system area in each app's space)?
> >Well, uh, doesn't that mean we can pass pointers without fear of memory
> >faults?
>
> I'd say the probability of someone using old extensions in a new system
> must be 1. Sure, passing pointers around inside a common memory space would
> be okay, but that means that nobody else could use your INITGestalt package.
> Why shouldn't processes in other memory spaces be able to use it as well?

Yes, I hope I don't have to chuck all my extensions for the new OS.
But, if they still work with the new OS, then they will likely have to
be located in some shared memory area (shared by all apps, that is),
and any INIT registration mechanism will likewise be located in shared
memory.  This means that "processes in other memory spaces" _will_ be
able to use the INITGestalt package.  Of course I don't pretend to know
how the new OS will handle old-style extensions, so we should not .

> You could use the Component Manager in a couple of ways. One would be to
> write a standard component which maintains a database of services which
> register themselves. Another would be to have each extension register itself
> as a component of type 'INIT' or something like that. The Component
> Manager provides nice tools for finding particular components or all
> the components of a particular type, which seems to be the functionality
> you're looking for.

Thanks for taking a stab at explaining the possibilities with the
component manager.  The fact that this functionality is available in an
existing manager is indeed justification enough for using it over
Gestalt.  One question remains:  what is the availability of the
component manager?  Is it only present with QuickTime? System 7?  Is
there an extension for System 6?  How about System 3.2?  ;-)  Gestalt
has this weakness, too (available only only on recent systems).

> Extensions registering as components could support
> any number of useful functions, including calls to turn them on/off,
> provide information about themselves, report how much memory they're
> currently using, report whether they're currently working or not and
> why ("This extension was turned off by the user"/"This extension doesn't
> work with virtual memory"), etc. Individual extensions could also provide
> extended interfaces for easy integration with other kinds of code.
> Hmmm... this is sounding good... maybe I'll go write some of this up
> tonight.

Yes, this much we have already figured out - what you outline is what
the initial proposal was trying to accomplish.  But don't let me stop
you from providing the implementation!  Before you do so, I suggest you
read the original proposal, which you can get from its authors by
sending mail to [e-mail].

I can hardly wait to use your code ;-)

Mark.


+++++++++++++++++++++++++++

>From [e-mail] (Caleb Strockbine)
Date: 12 Feb 1995 15:33:46 GMT
Organization: SUNY Stony Brook

In article <3hiugd$[e-mail]> [e-mail] ([e-mail]) writes:
>Thanks for taking a stab at explaining the possibilities with the
>component manager.  The fact that this functionality is available in an


Sure thing. I'd be pleased if Grobbins would tell us whether what I described
is close to what he was thinking. Good to have agreement on these things.


>existing manager is indeed justification enough for using it over
>Gestalt.  One question remains:  what is the availability of the
>component manager?  Is it only present with QuickTime? System 7?  Is
>there an extension for System 6?  How about System 3.2?  ;-)  Gestalt
>has this weakness, too (available only only on recent systems).


>From "NIM: More Macintosh Toolbox":
  "The Component Manager is available in System 7.1 or later and may
   be present in System 7..."

It's also available anywhere QuickTime is found. Plenty of other
parts of the system use it as well.


>read the original proposal, which you can get from its authors by
>sending mail to [e-mail].


I've got it saved somewhere...I'll certainly re-read it.


>I can hardly wait to use your code ;-)


I can hardly wait to use it myself! :-) Suggestions from anyone who cares
to make them are always welcome.

Caleb Strockbine
[e-mail]
--

.........................................................................
"It isn't always just how you look. Look at me. I'm handsome like anything
 and I haven't got anybody to marry me yet." -- Brian, age 7

+++++++++++++++++++++++++++

>From Michael D. Moore <[e-mail]>
Date: 13 Feb 1995 03:58:07 GMT
Organization: -

In article <[e-mail]> Matthew Xavier Mora,
[e-mail] writes:
>In article <3h5sjg$[e-mail]>, [e-mail] (Grobbins) wrote:
>> There are supported interfaces usable by non-application code, such as
>> the interfaces provided for drivers and components, and the PPC Toolbox
>> is a supported communications mechanism for all types of code.  Passing
>> around handles and procptrs may be simple, but it's poor practice and
>> will tend to bite you later.
>
>Could you please expand on what we would need to do to use either PPC
>toolbox or the component manager  instead of Gestalt?

Agreed.  I switched from using a "null" device driver to store the address
of my globals to a Gestalt function because I was told that creating
additional device drivers is a bad idea (agreed!).  When I saw Mr.
Grobbins
article, I was wondering how he would suppose to use PPC to communicate
this
information from an INIT.  Maybe installing a system (global) event
handler?
I could use some more information on that.

I was more interested in the Component Manager idea, so I read up on it.
It's
quite a bit more work, but I could do it.  However, I cannot find a list
of
existing component types or the information on how to register a new one.
 The
IM docs suggest it should and must be registered, but AppleLink, the TIL
and
Apple's WWW and FTP offer no information on the Component Registry.  Some
info
on this would help if this is the "right way" to do things.

Thanks,

Michael
- -------------------------
Official Motto of the Federal Government:
"This Motto Alone Cost $13.2 Billion"  -Dave Barry

+++++++++++++++++++++++++++

>From [e-mail] (Brian Stern)
Date: 13 Feb 1995 15:14:04 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <3h5sjg$[e-mail]>, [e-mail] (Grobbins) wrote:

< Publicizing pointers and handles with the Gestalt Manager is convenient,
< but it's also an abuse of the Gestalt facility.  The notion of getting
< a pointer to a completely independent piece of code is very non-savvy
< with respect to any future architectures that provide for multiple
< address spaces.
<
< There are supported interfaces usable by non-application code, such as
< the interfaces provided for drivers and components, and the PPC Toolbox
< is a supported communications mechanism for all types of code.  Passing
< around handles and procptrs may be simple, but it's poor practice and
< will tend to bite you later.
<
< Grobbins                      [e-mail]
<
< Usual disclaimers apply.

OK.  I'm convinced that using the Component Manager is the way to go
here.  I don't think PPC toolbox is appropriate in most cases.  Usually
we're only talking about a few bytes that need to be transferred between
INITs and CDEVs or applications.

I think that Apple should take the lead here.  We need an 'init' component
defined, along with a few messages.  I think 'turn on', turn off', 'get
status' and 'set status' messages should be defined.  Maybe a few others
as well.

The SAVR/SAVC mechanism is a gestalt-based method for doing these sorts of
things.  A Component Manager-based mechanism should be able to do what
SAVR/SAVC does without being much more complex.

We need sample code including a standard header file to be used for all
INITs that use this mechanism.

I think there would be lots of benefits from a standard interface for all
conforming extensions.  Imagine being able to turn off specified inits
from applications.

--
Brian  Stern  :-{)}
Toolbox commando and Menu bard
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Mon, 13 Feb 1995 07:38:05 -0800
Organization: Internet for the Olympic Peninsula

Component Manager availability:

   System 7.1 and up.

   Prior systems with QuickTime installed (as far back as QT will install,
whatever that 6.0.???).

       --John

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
       Isn't C fun?
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Caleb Strockbine)
Date: 13 Feb 1995 18:55:22 GMT
Organization: SUNY Stony Brook

In article <[e-mail]> [e-mail] (Brian Stern) writes:
>OK.  I'm convinced that using the Component Manager is the way to go
>here.  I don't think PPC toolbox is appropriate in most cases.  Usually

Good! A concensus is forming!

>I think that Apple should take the lead here.  We need an 'init' component
>defined, along with a few messages.  I think 'turn on', turn off', 'get
>status' and 'set status' messages should be defined.  Maybe a few others

Yikes! I'm halfway done already! Hope I don't get nosed out by Apple... :-)
I've got messages for turning extensions on and off, getting their status,
and getting information already defined. I've been thinking it might be
useful if an extension could also tell you what traps it patches, so that
might be a seperate message. Can anyone think of anything else that'd
be useful?

>The SAVR/SAVC mechanism is a gestalt-based method for doing these sorts of
>things.  A Component Manager-based mechanism should be able to do what
>SAVR/SAVC does without being much more complex.

What I've got so far is pretty simple. Easy to understand and easy to use.
Then again, I wrote it... I suppose I should let everyone else decide how
easy to use it really is. But there's honestly nothing very complicated.
High on my list of priorities is making it very easy to convert old-style
extensions to use the component interface.

>We need sample code including a standard header file to be used for all
>INITs that use this mechanism.

Got that.

>I think there would be lots of benefits from a standard interface for all
>conforming extensions.  Imagine being able to turn off specified inits
>from applications.

Exactly. Or get a list of all installed conforming extensions. I'll make
what I've done available as soon as it's done. I don't want to make
promises I can't keep, but it shouldn't be very long.

Caleb Strockbine
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] ([e-mail])
Date: 13 Feb 1995 22:38:44 GMT
Organization: Dartmouth College, Hanover, NH

In article <3ho9uq$[e-mail]>
[e-mail] (Caleb Strockbine) writes:
> >I think that Apple should take the lead here.  We need an 'init' component
> >defined, along with a few messages.  I think 'turn on', turn off', 'get
> >status' and 'set status' messages should be defined.  Maybe a few others
>
> Yikes! I'm halfway done already! Hope I don't get nosed out by Apple... :-)
> I've got messages for turning extensions on and off, getting their status,
> and getting information already defined. I've been thinking it might be
> useful if an extension could also tell you what traps it patches, so that
> might be a seperate message. Can anyone think of anything else that'd
> be useful?

I disagree that we should depend on Apple to do this.  They do not have
a monopoly on good design, nor do they have infinite resources.  Let's
leave them to concentrate on making a great OS, and we can fill in the
utilities ;-)

Now, I'd really like to see some comments from the original proposers,
who have already written some code, and who might have some design
ideas for a Component Manager based solution.  Are you guys out there?

Mark.


+++++++++++++++++++++++++++

>From [e-mail] (Kent Sandvik)
Date: Tue, 14 Feb 1995 23:24:37 -0800
Organization: Apple Computer, Inc. Developer Technical Support

In article <3gqv1h$[e-mail]>,
[e-mail] ([e-mail]) wrote:
> For instance, I'm not convinced that the Component Manager is the right
> solution (I don't know that much about it, though).  What I do know is
> that the Component Manager was originally part of QuickTime.  Is it
> built into all versions of System 7?  When does it load?  Can it be
> loaded by an INIT if it is not there?  Will we have to license it from
> Apple in order to get it on System 7.0?  Can it run under System 6
> (this would be good, because Gestalt is not implemented on all
> systems)?  What are the real drawbacks, if there are any?

The Component Manager is installed from System 7.1 forward, or if Sound
Manager 3.0 is installed, or if QuickTime, or ColorSync, or
AppleScripting, or similar Apple extensions are installed.

It should supposedly work with System 6. I don't know if we rev the
Component manage due to System 6 bugs, though.

> I agree that the design of this INIT Gestalt gizmo has much in common
> with the Component Manager, but the code is so ultra-trivial that it
> would not really be "re-inventing the wheel" to write a few queue
> access routines.
>
> So, convince everyone (who's listening) that the Component Manager is
> the way to go, and you may just save us from ourselves ;-)
It's another way to provide shared code/libraries/globals for an
application. Compare this one with CFM and ASLM, and select the best one
for your purpose. It will be around for a very long time as QuickTime,
Sound Manager and other similar extensions need it.

--Kent

--
Kent Sandvik   [e-mail]   New Media Analyst/Programmer
Private activities on Internet.

+++++++++++++++++++++++++++

>From [e-mail] (Kent Sandvik)
Date: Mon, 20 Feb 1995 18:22:58 -0800
Organization: Apple Computer, Inc. Developer Technical Support

In article <[e-mail]>,
[e-mail] (Brian Stern) wrote:
> I remember looking at the INIT-CDEV example when I first needed this
> functionality and thinking that it was too complicated.  I just looked at
> it again and I understand it better now.  Of course this example goes to
> all this trouble to make a PPC-Toolbox connection between the INIT and the
> CDEV and what information does it pass?  A pointer to the INIT's globals.
> Oh well.

The components have a built-in refcon value that could be passed along
using the SetComponentRefCon and GetComponentRefCon.

--Kent

--
Kent Sandvik   [e-mail]   New Media Analyst/Programmer
Private activities on Internet.

---------------------------

>From John Kawakami <[e-mail]>
Subject: Information on installer maker companies
Date: Fri, 17 Feb 1995 02:20:36 GMT
Organization: Xplain Corp.

Someone forwarded a question to the info group about installers.  The
reply looked informative enough to post, so here it is:

> Date: 2/16/95 2:42 AM
> To: John Kawakami
> From: Aadjan van der Helm
>
> Hello
>
> I would like to use the standard Apple installer to install homebrew
> software. I couldn't find any info on this in the relevant FAQ.
>
> Do you know howto customize the behaviour of this installer, or can
> you point me to people who do?
>
> Thanks for reading this
> --Aadjan ([e-mail])
- -------------------
From: John Kawakami (2/16/95)
To: Aadjan van der Helm

***

A simple way to get around creating an installer is to distribute your program
 as a self extracting archive.  When the user decompresses the archive, she will
 be asked where she wishes to store the files.

In May 1994, MacTech did a summary review of several installer utilities.
Here's are the companies mentioned in that article:

Apple Installer.  Apple Computer, Inc.  [phone].  AppleLink: SW.LICENSE.
 Information is also available on E.T.O.

Developer VISE. MindVision Software. PO Box 81886, Lincoln, Nebraska, 68501.
 [phone] voice, [phone] fax. AOL, AppleLink: MindVision;
 CompuServe: 70253,1437.

DragInstall. Ray Sauers Associates. 1187 Main Avenue, Suite 1B. Clifton, New
 Jersey, 07011. [phone]. AOL: Sauers; CompuServe: 70731,2326; AppleLink:
 D1922.

Script-Ease. Glen Canyon Software. 3921 Shasta View. Eugene, OR. 97405. (800)
 477-6947 or [phone]. AppleLink: GlenCanyon

ScriptGen Pro and InstallerPack. StepUp Software. 710 Glendora Avenue, Dallas,
 Texas  75230-5428.  [phone] voice, [phone] fax.  AppleLink:
 StepUp; AOL: StepUp1; CIS: 73607,3630.

Smaller Installer. Cyclos. PO Box 31417, San Francisco, CA 94131-0417. (415)
 821-1448. AppleLink: CYCLOS; CompuServe: 71101,204.

StuffIt InstallerMaker. Aladdin Systems. 165 Westridge Drive. Watsonville, CA
 95076. [phone] voice, [phone] fax. AOL, AppleLink: Aladdin;
 CompuServe: 75300,1666.

John Kawakami, [e-mail]
- -comp.sys.mac.programmer.info--------------------------------------
comp.sys.mac.programmer.info is primarily for distributing FAQs,
tutorials, news, and similar documents  related to programming the
Macintosh.  To post, email [e-mail]
- -MacTech Magazine--------------------------------------------------
PO Box 250055, Los Angeles, CA 90025, 310-575-4343, Fax:[phone]
For more info, ftp://ftp.netcom.com/pub/xp/xplain

---------------------------

>From [e-mail] (Christina Schulman)
Subject: Sound Manager clicking with sampled sounds
Date: 14 Feb 1995 16:25:50 GMT
Organization: St. Dismas Infirmary for the Incurably Informed

As long as we're sharing our woes with the Sound Manager, I've
been completely unsuccessful in trying to prevent irritating clicking
at the start of sampled sounds, and I'd be very grateful if
anyone could suggest a fix.

I'm using Think C 7.0 on a Quadra 800, 16 Mb RAM, System 7.1.

I'm reading a succession of sampled sounds, many of them large,
in from a file in AIFF format.  I can't use SndStartFilePlay()
because they're embedded in a single file, and as far as I can tell,
the Sound Manager doesn't provide high-level routines to play
AIFF's from memory.

So I'm reading the sound in, finding the start of the sampled sound
data, backtracking by the size of a SndListResource and SoundHeader,
writing in my own header information so that it thinks it's a
format 1 'snd ' resource, and passing this to SndPlay.  Much to my
surprise, this works.  Unfortunately, it also clicks at the start
of each sound.

Inside Mac obligingly informs me that repeated use of bufferCmd
(which I'm using) is not guaranteed to work on the Mac Plus, SE,
or Classic without an audible pause or click.  However, I'm using
a Q800, and this software will never run on a b/w Mac.  I tried
using soundCmd to install the sampled sound as a voice in my
sound channel (I'm allocating my own) and playing it with freqCmd,
but this didn't eliminate the clicking, so I don't think it's
due to the use of bufferCmd.

Help!  I'm sure I've seen someone asking about this here before,
but unfortunately I didn't pay attention at the time.

Here's the code which writes my sound headers:

// SndList Resource is the snd format 1 header

sl = (SndListPtr) (ch);
sl->format = 0x0001;                      // format 1
sl->numModifiers = 0x0001;
sl->modifierPart[0].modNumber = 0x0005;   // sampledSynth
sl->modifierPart[0].modInit = 0x00000000; // initMono
sl->numCommands = 1;
sl->commandPart[0].cmd = 0x8051;          // bufferCmd
sl->commandPart[0].param1 = 0x0000;       // ignored
sl->commandPart[0].param2 = 0x00000014;   // offset to sound header

shd = (SoundHeader *) (sl->dataPart);
shd->samplePtr = 0x00000000;  // NULL ptr means data follows immediately
shd->length = numBytes;       // taken from the AIFF common chunk
shd->sampleRate = rate11khz;
shd->loopStart = 0x00000000;
shd->loopEnd = 0x00000000;    // no looping desired
shd->encode = stdSH;          // standard SoundHeader
shd->baseFrequency = 0x3C;    // 60 == middle C


Thanks in advance for any advice.

--
Christina Schulman                                       [e-mail]

+++++++++++++++++++++++++++

>From "Andrew C. Plotkin" <[e-mail]>
Date: Tue, 14 Feb 1995 15:00:17 -0500
Organization: Information Technology Center, Carnegie Mellon, Pittsburgh, PA

Excerpts from netnews.comp.sys.mac.programmer.help: 14-Feb-95 Sound
Manager clicking with.. Christina Schulman@pitt. (2528)

> I'm reading a succession of sampled sounds, many of them large,
> in from a file in AIFF format.  I can't use SndStartFilePlay()
> because they're embedded in a single file, and as far as I can tell,
> the Sound Manager doesn't provide high-level routines to play
> AIFF's from memory.

> So I'm reading the sound in, finding the start of the sampled sound
> data, backtracking by the size of a SndListResource and SoundHeader,
> writing in my own header information so that it thinks it's a
> format 1 'snd ' resource, and passing this to SndPlay.  Much to my
> surprise, this works.  Unfortunately, it also clicks at the start
> of each sound.

Hurm. Is the data in the "right" format (8-bit unsigned samples, with
0x80 as the centerline? I don't know AIFF, but sounds are sometimes
stored as signed numbers with 0x00 as the center.)

Does each sound start and end with silence?

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D9Oliveiro)
Date: Wed, 15 Feb 1995 18:08:28 +1300
Organization: University of Waikato

In article <3hqlie$[e-mail]>, [e-mail]
(Christina Schulman) wrote:

>As long as we're sharing our woes with the Sound Manager, I've
>been completely unsuccessful in trying to prevent irritating clicking
>at the start of sampled sounds, and I'd be very grateful if
>anyone could suggest a fix.
>
>I'm using Think C 7.0 on a Quadra 800, 16 Mb RAM, System 7.1.
>
...
>
>So I'm reading the sound in, finding the start of the sampled sound
>data, backtracking by the size of a SndListResource and SoundHeader,
>writing in my own header information so that it thinks it's a
>format 1 'snd ' resource, and passing this to SndPlay.  Much to my
>surprise, this works.  Unfortunately, it also clicks at the start
>of each sound.

Don't use SndPlay for this. Instead, open a channel, initialize it for the
sampled-sound synth, and for each block of sound data, create a
SoundHeader structure, and feed it to the channel via a bufferCmd command,
using SndDoCommand.

Tips:

1) To prevent pauses between the bufferfuls, make sure there's always
another bufferCmd command waiting in the queue before the current one
finishes. You can put a callBackCmd after every bufferCmd: the callback
will be delivered when the buffer finishes playing. This will tell you
when the next one starts, so you can immediately queue yet another
bufferful to be ready before that one finishes.
2) Installing Sound Manager 3.0 is *highly* recommended. Better
performance, no strange shifts in volume when you open/close channels,
transparent 8/16-bit conversion, and more. If you install System Update
3.0 (which you should have done), you will get the new Sound Manager.

+++++++++++++++++++++++++++

>From [e-mail] (In The Dark Water)
Date: 16 Feb 1995 03:54:14 GMT
Organization: Vnet Internet Access, Charlotte, NC -  [e-mail]

Christina Schulman ([e-mail]) wrote:
: As long as we're sharing our woes with the Sound Manager, I've
: been completely unsuccessful in trying to prevent irritating clicking
: at the start of sampled sounds, and I'd be very grateful if
: anyone could suggest a fix.

This may not be a fix, but here's a couple points to consider.  The
'click' or 'pop' is usually the Sound Manager turns on the sound
hardware.  The clicking noise results often from the current sound to be
played being at a level different from the sound just being played.  This
can also happen when a sound finishes playing, and the speaker returns to
its resting position.

In his excellent book "Ultimate Mac Programming", Dave Mark spends a
whole chapter on the Sound Manager, and includes some interesting source
code and sample applications.

He proposes this workaround for this problem.  Try ending your sounds
with a buffer of silence.  Dave says this buffer need only be about 2K of
22KHz data and helps settle out the hardware.  This solved the problem
for me in the application I'm writing.  I don't know whether this will
help, but I have some sample code, if you'd like.

Your code looks good; this solution may not be feasible, and I don't know
how involved your app is, but if you'd like, send me some email and we'll
take another look.


Thanks,

Brian Neal
Starving Mac Programmer
Charlotte NC
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Christina Schulman)
Date: 16 Feb 1995 05:54:55 GMT
Organization: St. Dismas Infirmary for the Incurably Informed

I complained:
>>So I'm reading the sound in, finding the start of the sampled sound
>>data, backtracking by the size of a SndListResource and SoundHeader,
>>writing in my own header information so that it thinks it's a
>>format 1 'snd ' resource, and passing this to SndPlay.  Much to my
>>surprise, this works.  Unfortunately, it also clicks at the start
>>of each sound.

Jean-Yves Bernier <[e-mail]> replied:
>Look at your first sound samples: they must be begin at $80 and raise or
>fall smoothly. $80 is the value converting to 0 volts (in offset-binary).
>If you use 16-bit samples, this value must be 0 (two's complement).

This turned out to be the problem; I was so convinced the the click
was the result of activating the speaker that I hadn't examined the
sound samples closely enough.

Each sound does begin and end with silence, but buried several bytes
into each sample were 8 bytes that were producing the click.  I have
no idea where these came from; they're certainly not *supposed*
to be there.

I ended up kludging it--if the first few bytes at that offset match
the first few "click bytes," I set the 8 bytes at that offset to
0x80.  Presto, no more clicking!

Thanks for your help, everybody.  This is the last time I trust an
IBM programmer to give me clean sound samples!

--
Christina Schulman                                       [e-mail]

---------------------------

>From [e-mail] (Tony Nardo)
Subject: VBL, time manager interrupts on PPC
Date: 14 Feb 1995 13:15:59 GMT
Organization: Johns Hopkins University Applied Physics Lab, Columbia, MD, USA

We are considering migrating some of our C code (developed under MPW) from
a Quadra to a PowerMac.  One potential problem in this migration is in
converting in-line assembly statements.  Currently, we use such statements
in establishing pointers to VBL and time manager control blocks via registers
A0 and A1, respectively.

Questions:
        - does MPW or CodeWarrior support a better mechanism for recovering
          the VBL or timer control structure from within their respective
          interrupt?
        - does either support a clean mechanism for saving registers upon
          entry into such a routine?  (We found that saving all registers
          immediately on entry to our VBL/timer interrupts cleared up a
          few pesky problems.  I'd prefer to retain that capability.)
        - where can I find documentation on transitioning VBL/timer interrupt
          support from a 680x0 architecture to the PPC?

Thanks,
--
Tony Nardo,                INET: [e-mail], [e-mail]
 Johns Hopkins Univ./APL   UUCP: {backbone!}mimsy!aplcomm!trn

+++++++++++++++++++++++++++

>From [e-mail] (Matthew Xavier Mora)
Date: Tue, 14 Feb 1995 09:36:48 -0800
Organization: SRI International

In article <3hqaef$[e-mail]>, [e-mail] (Tony
Nardo) wrote:

> Questions:
>         - does MPW or CodeWarrior support a better mechanism for recovering
>           the VBL or timer control structure from within their respective
>           interrupt?
>         - does either support a clean mechanism for saving registers upon
>           entry into such a routine?  (We found that saving all registers
>           immediately on entry to our VBL/timer interrupts cleared up a
>           few pesky problems.  I'd prefer to retain that capability.)
>         - where can I find documentation on transitioning VBL/timer interrupt
>           support from a 680x0 architecture to the PPC?



For performance reasons, you may want to hold off porting your VBLs/timers
interrupts to powerpc. The VBL and Interrupt mechanism on the PPC
is emulated. Doing mixed mode manager mode switches 60 times a second
is not something you want to do. :-)

These are all good question and I think most of the can be answered in IM
Power pc programming (I forget the name of that volume.)



Xavier

--
__________________________________________________________________
Matthew Xavier Mora  (cybernaut)            The keeper of the UMPG
SRI International                              [e-mail]

"Indeed, it would not be an exaggeration to describe the history
of the computer industry for the past decade as a massive attempt
to keep up with Apple." Byte 12/94

My home page. <http://xavier.sri.com>
The WWW UMPG: <http://xavier.sri.com/umpg.html>
__________________________________________________________________

+++++++++++++++++++++++++++

>From [e-mail] (Tony Nardo)
Date: 15 Feb 1995 18:00:15 GMT
Organization: Johns Hopkins University Applied Physics Lab, Columbia, MD, USA

In response to my questions, [e-mail] (Matthew Xavier Mora) writes:

>For performance reasons, you may want to hold off porting your VBLs/timers
>interrupts to powerpc. The VBL and Interrupt mechanism on the PPC
>is emulated. Doing mixed mode manager mode switches 60 times a second
>is not something you want to do. :-)

Thanks for the heads-up on that.  Would anyone happen to know where I can find
a way to evaluate just how much PPC performance is impacted by a mixed mode
manager switch; i.e. how much time does each switch take?

>These [below] are all good question and I think most of the can be answered
>in IM Power pc programming (I forget the name of that volume.)

Someone else pointed me at E.T.O. (Essentials, Tools, Objects) #15.  I'll
pass on what I found, and the new questions that arose.

>> Questions:
>>         - does MPW or CodeWarrior support a better mechanism for recovering
>>           the VBL or timer control structure from within their respective
>>           interrupt?

This turns out to be somewhat of a non-issue.  Our whole reason for wanting
to recover the VBL/timer structure was to pick up the A5 register value from
the parent process, so that we could get at our global data.  SetA5() is no
longer necessary on the PPC to accomplish this, so the point is now moot for
our applications.

ETO also noted that a pointer the control structure for a VBL interrupt is
passed as a formal parameter into the interrupt service routine.  There was
no explicit mention of time manager interrupts, but one hopes that the same
mechanism applies.

>>         - does either support a clean mechanism for saving registers upon
>>           entry into such a routine?  (We found that saving all registers
>>           immediately on entry to our VBL/timer interrupts cleared up a
>>           few pesky problems.  I'd prefer to retain that capability.)

This question should perhaps be rephrased: in CodeWarrior and/or MPW's PPCC,
are *all* registers preserved in each function?

MPW C for the 680x0 made no attempt to preserve registers D0, D1, A0 and A1
in a C function.  (This is not very convienient for those who wish to develop
C interrupt routines! :-) )  A cursory reading of the notes in ETO 15 suggests
that all PPC registers used by a function are preserved by PPCC within that
function (assuming local optimization and no inlining), but this is not
explicitly stated.

>>         - where can I find documentation on transitioning VBL/timer interrupt
>>           support from a 680x0 architecture to the PPC?

ETO 15 provides some details, but no mention was made of VBL/timer interrupts
being emulated.  Where may I find those notes?
--
Tony Nardo,                INET: [e-mail], [e-mail]
 Johns Hopkins Univ./APL   UUCP: {backbone!}mimsy!aplcomm!trn

+++++++++++++++++++++++++++

>From [e-mail] (Bruce Hoult)
Date: Fri, 17 Feb 1995 16:27:17 +1300 (NZDT)
Organization: (none)

[e-mail] (Tony Nardo) writes:
> >>         - does either support a clean mechanism for saving registers upon
> >>           entry into such a routine?  (We found that saving all registers
> >>           immediately on entry to our VBL/timer interrupts cleared up a
> >>           few pesky problems.  I'd prefer to retain that capability.)
>
> This question should perhaps be rephrased: in CodeWarrior and/or MPW's PPCC,
> are *all* registers preserved in each function?
>
> MPW C for the 680x0 made no attempt to preserve registers D0, D1, A0 and A1
> in a C function.  (This is not very convienient for those who wish to develop
> C interrupt routines! :-) )  A cursory reading of the notes in ETO 15 suggests
> that all PPC registers used by a function are preserved by PPCC within that
> function (assuming local optimization and no inlining), but this is not
> explicitly stated.

The answer is "no".  General PPC functions can and do clobber registers r0 and
r3-r12.

I would expect that Apple's PPC interrupt handler will be saving and
restoring everything for you so you don't have to worry about it.

-- Bruce

---------------------------

>From [e-mail] (Jeffrey Johnson)
Subject: anything *bad* about mixing alignment types in CW?
Date: 16 Feb 1995 11:42:28 -0800
Organization: CRL Dialup Internet Access        [phone]  [Login: guest]

I'm building an app with the AppsToGo framework, and I'm at the point of
trying to get it to run a wee bit faster. After reading the docs on the
CW5 disk, I decided to try setting my project to PowerPC struct alignment
from 68K alignment to get things to move in memory faster.

Boy, that was fun :-). The Gworld layers code terminated me immediately
on a GetGWorldPixMap, but then hummed along like nothing was wrong after
resetting to 68K alignment.

in another area, I tried using Tim Olson's bzero(void*,int) instead of
memset(x,0,size) to clear the float array foo[x][y] with bzero(foo,x*y*4).
This resulted in an access fault almost immediately (*of course* it could
be something my code is stomping on, but the memset seems to work).. I'm
guessing that could this be from my float array not being aligned on a
quadword boundary?

So now I seem to have good reasons for aligning my project either
way...Help!

Thanks
Jeff


--
Jeffrey Johnson                                               [e-mail]
If you believe what you read, the sky is thick with aliens who are designing
pyramids, disemboweling livestock, impregnating rural people and generally
having a good time at our expense.  -Scott Adams

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Sat, 18 Feb 1995 22:39:21 -0800
Organization: Internet for the Olympic Peninsula

In article <3i09r4$[e-mail]>, [e-mail] (Jeffrey Johnson) wrote:

> I'm building an app with the AppsToGo framework, and I'm at the point of
> trying to get it to run a wee bit faster. After reading the docs on the
> CW5 disk, I decided to try setting my project to PowerPC struct alignment
> from 68K alignment to get things to move in memory faster.
>
> Boy, that was fun :-). The Gworld layers code terminated me immediately
> on a GetGWorldPixMap, but then hummed along like nothing was wrong after
> resetting to 68K alignment.
>
> in another area, I tried using Tim Olson's bzero(void*,int) instead of
> memset(x,0,size) to clear the float array foo[x][y] with bzero(foo,x*y*4).
> This resulted in an access fault almost immediately (*of course* it could
> be something my code is stomping on, but the memset seems to work).. I'm
> guessing that could this be from my float array not being aligned on a
> quadword boundary?
>
> So now I seem to have good reasons for aligning my project either
> way...Help!

Any struct the toolbox thinks it knows about had better be aligned the way
the toolbox thinks it is:  68K.

Any struct the toolbox doesn't know about needs only be consistently
aligned everywhere in your code.  And if you write it into files, that
still holds:  both your 68K version and your PPC version should treat it
the same in the file (whichever way it is).  Or destructurize it for
filing purposes.

Of course, we all use Bento for filing now, don't we?  --John

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
       Isn't C fun?
   [e-mail]

---------------------------

>From [e-mail] (David Knuth)
Subject: custom ClikLoop problem
Date: Fri, 17 Feb 1995 17:40:29 GMT
Organization: Loral Medical Imaging Systems

I am having trouble with my custom click loop for a list.  I'm trying
to have the list update dynamically as the list is scrolled (i.e.,
manually draw grey grid lines around all the cells--the data is updated
automatically by LClick), however call-back routine is only called when
a mouse-down occurs in the rView rect (the area where the cells are).
No mouse-down event is reported when the mouse-down is in the scroll
bar.  How can I remedy this?

Thanks

David Knuth
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Sean Crist)
Date: 17 Feb 1995 21:51:57 GMT
Organization: University of Pennsylvania, Linguistics Department

In article <[e-mail]>,
David Knuth <[e-mail]> wrote:
>I am having trouble with my custom click loop for a list.  I'm trying
>to have the list update dynamically as the list is scrolled (i.e.,
>manually draw grey grid lines around all the cells--the data is updated
>automatically by LClick), however call-back routine is only called when
>a mouse-down occurs in the rView rect (the area where the cells are).
>No mouse-down event is reported when the mouse-down is in the scroll
>bar.  How can I remedy this?

Assuming you're using a custom LDEF, why don't you just draw the grid lines
as part of your cell?  The List Manager doesn't clip the drawing your LDEF
does to particular cells; you can scribble all over the window if you like.

If you're not using a custom LDEF, I'd recommend that you do so; they're
easy to write, as long as you do the business of jumping from an LDEF stub
into your main code (I assume you know what I'm talking about; ask me if
you need to know how to do this).

  \/ __ __    _\_     --Sean Crist  ([e-mail])
 ---  |  |    \ /     For a free copy of the Bill of Rights, finger
  _| ,| ,|   -----       this account.
  _| ,| ,|    [_]     Q: What do Standard Oil, AT&T, and Microsoft have in
   |  |  |    [_]        common?   A:  Nothing... yet.

+++++++++++++++++++++++++++

>From [e-mail] (Daniel Sears)
Date: Sun, 19 Feb 1995 06:19:22 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

[e-mail] (David Knuth) writes:

>I am having trouble with my custom click loop for a list.  I'm trying
>to have the list update dynamically as the list is scrolled (i.e.,
>manually draw grey grid lines around all the cells--the data is updated
>automatically by LClick), however call-back routine is only called when
>a mouse-down occurs in the rView rect (the area where the cells are).
>No mouse-down event is reported when the mouse-down is in the scroll
>bar.  How can I remedy this?

>Thanks

>David Knuth
>[e-mail]

Try this:

/*
 * Adapted from Michael Hecht's code.
 * This works around a bug in the PowerMacintosh ROM
 * click_loop_glue is a quick & dirty way of doing
 * inline 68K assembly from PowerPC code.
 * We need to do this because if we have the List Manager
 * call our native click loop directly,
 * it can fail because the List Manager doesn't actually
 * test the result in D0, it just checks the state of the Z-bit,
 * which Mixed Mode doesn't set for us.
 *
 * Example:
 *
 *              pascal Boolean  ClickLoopProc(void);
 *
 *              #ifdef  powerc
 *                      if (PPC_LClick(event->where, event->modifiers, list, ClickLoopProc)) {
 *                      }
 *              #else
 *                      (*list)->lClikLoop = ClickLoopProc;
 *                      if (LClick(event->where, event->modifiers, list)) {
 *                      }
 *              #endif
 */
Boolean
PPC_LClick(
        Point where,
        short modifiers,
        ListHandle list,
        pascal Boolean (*click_loop)(void))
{
        ListClickLoopUPP cl_upp;
        long result;
        static struct {
                unsigned short          cl_glue[6];
                ListClickLoopUPP        cl_upp;                 // Storage for the UPP
        } click_loop_glue = {
                {
                        0x207A, 0x000A,                                 // MOVEA.L      click_loop_glue.cl_upp,A0
                        0x4E90,                                                 // JSR          (A0)
                        0x4A00,                                                 // TST.B        D0
                        0x4E75,                                                 // RTS
                        0x4E71                                                  // NOP          -- pad to longword
                },
                0                                                                       // cl_upp
        };

        cl_upp = NewListClickLoopProc(click_loop);
        click_loop_glue.cl_upp = cl_upp;
        cl_upp = (ListClickLoopUPP) &click_loop_glue;

        (*list)->lClickLoop = cl_upp;                   // Set up clikLoop routine

        result = LClick(where, modifiers, list);

        (*list)->lClickLoop = 0;                                // Remove clikLoop routine

        /*
         * Put the real UPP back in the local so that we can dispose of it
         */
        cl_upp = click_loop_glue.cl_upp;
        DisposeRoutineDescriptor((UniversalProcPtr) cl_upp);
        return (Boolean) result;
}
--
E-mail:     [e-mail]
Phone:      [phone]
Address:    2440 16th Street #283
            San Francisco, CA
            94103-4211

This email message sent with 100% recycled bits.

---------------------------

End of C.S.M.P. Digest
**********************